XML support from DXL -- Native Perms vs. COM Add-On

Mathias Mamsch - Wed Dec 28 09:29:30 EST 2011
In principle you are right. The DOORS native perms only allow reading XML, but not writing XML (there is no toString or saveFile function!). So to write XML you would need to go to a COM library or effectively write your own XML creation library (like for example IBM did with their Rational Publishing Engine. This is pretty straight forward I guess, you just need to take care about correct escaping and performance.

You should take into account the availability of the XML DOM Library. As far as I know they ship with each Windows since XP Service Pack 2 (no one should use an older version) and are also available if .NET is installed. Therefore I guess you can safely assume, that the XML Services are available on all computers you will find. By the way, I am pretty sure that the DOORS client itself uses MS XML for their internal DXL functions ;-).

Regards, Mathias

SystemAdmin - Wed Dec 28 12:49:57 EST 2011

Thanks for your insights Mathias. I'm at a company where the general population that would be using the proposed functionality has (Windows XP, Office 2003, and DOORS 9.3). That said, it sounds like it would be likely that they would have some version of MSXML*.dll on their machine already.

One additional fear ... is it necessary to specify the ActiveX version when you instantiate? I don't think I'll be using anything "cutting edge" but I'm fearful the user community nay have all sorts of different versions of MSXML*.dll

If I look on my system I see:

C:\WINDOWS\system32>dir msxml*.* /od
 Volume in drive C is Windows
 Volume Serial Number is 9451-C697
 
 Directory of C:\WINDOWS\system32
 
04/18/2003  04:29 PM            82,432 msxml4r.dll
08/04/2004  04:00 AM            37,916 msxml2r.dll
08/04/2004  04:00 AM            44,032 msxml3r.dll
08/04/2004  04:00 AM            26,624 msxmlr.dll
04/13/2008  10:57 PM            79,872 msxml6r.dll
04/14/2008  05:42 AM           506,368 msxml.dll
04/14/2008  05:42 AM           701,440 msxml2.dll
07/21/2009  12:05 AM         1,348,432 msxml4.dll
07/31/2009  10:05 AM         1,372,672 msxml6.dll
06/13/2010  11:41 PM         1,172,480 msxml3.dll
              10 File(s)      5,372,268 bytes
               0 Dir(s)  10,070,888,448 bytes free
 
C:\WINDOWS\system32>

Often I semi-debug com sorts of things as Word VBA so I can debug a bit easier. I noticed in one of your past examples you had a statement that included the version as well as the control:

OleAutoObj objDAO = oleCreateAutoObject "DAO.DBEngine.36"

I think the 36 corresponds to Microsoft DAO 3.6 Object Library.

Do I have to put in a version? If so maybe I could I a list of different ones that would work and try them in order of preference.

Perhaps something like this:

OleAutoObj domDocMsXml = null;
 
bool didOnce;
// Try in order of preference.
// Break out of { block } upon first success ...
for(didOnce = false; !didOnce; didOnce = true) {
    // Try version 6.0 ...
    domDocMsXml = oleCreateAutoObject("Msxml2.DOMDocument.6.0");
    if (!null(domDocMsXml)) break;
 
    // Try version 5.0 ...
    domDocMsXml = oleCreateAutoObject("Msxml2.DOMDocument.5.0");
    if (!null(domDocMsXml)) break;
 
    // Try version 4.0 ...
    domDocMsXml = oleCreateAutoObject("Msxml2.DOMDocument.4.0");
    if (!null(domDocMsXml)) break;
 
    // Try version 3.0 ...
    domDocMsXml = oleCreateAutoObject("Msxml2.DOMDocument.3.0");
    if (!null(domDocMsXml)) break;
 
    // Try version 2.6 ...
    domDocMsXml = oleCreateAutoObject("Msxml2.DOMDocument.2.6");
    if (!null(domDocMsXml)) break;
 
    // ... and so on
 
    ack("No suitable MSXML*.dll was found.  Please download and install from ...");
    halt();
}
 
// other code that uses domDocMsXml

If the above a necessary evil to keep " ... hey it doesn't work on my machine ... " to a minimum?

Been there. Done that. Don't like it. Would rather think it out before diving into such a thing.

Any advice?

Mathias Mamsch - Wed Dec 28 16:32:40 EST 2011
Again you should be thinking about the differences between the MS XML Versions. I am not sure what you are planning to do exactly, but simply reading and creating an XML file by appending nodes to the trees, setting attributes, etc. can be done by every version of MSXML and it is highly unlikely that basic stuff like that changed completly between the versions. After all Microsoft has to think about backward compatibility too. There is lots of other stuff that you can do with MSXML: Web Services, XSLT, Schema validation, etc. Maybe you are not even interested in anything like that.

Therefore my guess is you can use ANY version of MSXML you find and your scripts will still run.

Regards, Mathias

SystemAdmin - Wed Dec 28 18:21:04 EST 2011
Sorry if I was not clear.

I agree with you that I could use most any version. My concern is (I think) you have to specify a version nevertheless. If you do have to specify a version, how does one handle that dilemma? If a certain version came with DOORS I could just specify the version that came with DOORS and be confident I won't get the problem ticket while I'm on vacation. Do you know how to find out what that version might be?

Sometimes flexibility in picking versions can be a benefit (if you need some new, specific feature), here it is a nuisance (unless there is an option where I don't have to specify the version, but I think you do now. I hope I'm wrong.)

Mathias Mamsch - Wed Dec 28 19:35:34 EST 2011

I am not aware that there is a need to specify a 'version'. The first thing you should note is that most of the time you can do:
 

OleAutoObj domDoc = oleCreateAutoObject("Msxml2.DOMDocument");
 
print null domDoc
 
oleCloseAutoObject domDoc

The next thing that should be noted is that the suffix you appended, was not a DLL version but a COM interface version. You can have a newer DLL installed that still features the old interfaces - in fact COM has been designed to do just that.

Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

SystemAdmin - Wed Dec 28 20:21:09 EST 2011

Based on your response, in your previous thread with the OLE access example, one could have substituted:
 

// CLSID: {00000100-0000-0010-8000-00AA006D2EA4}
 
OleAutoObj objDAO = oleCreateAutoObject "DAO.DBEngine.36"

with

OleAutoObj objDAO = oleCreateAutoObject "DAO.DBEngine"

Similarly, if I have this on my system:

// CLSID: {000209FF-0000-0000-C000-000000000046}
 
Word.Application.11

it sounds like I can drop the ".11" suffix at the end of the CLSID.

I wonder if there are are any "auto=rules" like the latest version will be used unless explicitly specified otherwise.

I'll try a few experiments and see if any smoke comes out.

Mathias Mamsch - Thu Dec 29 13:12:23 EST 2011

It is actually pretty easy. Normally each Application or DLL you install will register at least two keys (e.g. Word):
 

HKEY_CLASSES_ROOT / Word.Application 
HKEY_CLASSES_ROOT / Word.Application.8
HKEY_CLASSES_ROOT / Word.Application.11

Under these keys you find the CLSID subkey which points to the DLL entry under HKEY_CLASSES_ROOT / CLSID / {...Class ID...}

When you install a new version of the application, it will overwrite the key without the version number, so that this key
will always point to the most recent version, but the others still exist. So you can either choose to use the most recent version or a specific (older) version.

By the way, if a COM plugin does not work, it is always the best way to check HKEY_CLASSES_ROOT first for an CLSID entry and then navigate to the HKEY_CLASSES_ROOT / CLSID / folder to check if the DLL still exists and is accessible.

Maybe that helps, regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

SystemAdmin - Thu Dec 29 14:16:36 EST 2011

Your explanation sounds logical. Since you believe some some version of MsXMLxxx.DLL gets installed with the DOORS client, the statement below should resolve to something usable for core XML purposes:
 

// The below should install the Msxml2.DOMDocument with highest version
OleAutoObj domDocMsXml = oleCreateAutoObject("Msxml2.DOMDocument");

This is a separate but related issue but is there a way to determine what ActiveX controls get installed with various DOORS releases?

The user community may be using different versions of Windows and Office but they will be using the same DOORS release. If I have knowledge of (for example) what installed with DOORS V9.3 then I can be fairly confident a DOORS-installed ActiveX control's use will be fair game.

Thanks for your help.